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Linear and substructural types are powerful tools, but adding them to standard functional program¬ 
ming languages often means introducing extra annotations and typing machinery. We propose a 
lightweight substructural type system design that recasts the structural rules of weakening and con¬ 
traction as type classes; we demonstrate this design in a prototype language. Clamp. 

Clamp supports polymorphic substructural types as well as an expressive system of mutable 
references. At the same time, it adds little additional overhead to a standard Damas-Hindley-Milner 
type system enriched with type classes. We have established type safety for the core model and 
implemented a type checker with type inference in Haskell. 


1 Introduction 

Type classes EHH provide a way to constrain types by the operations they support. If the type class 
predicate Du pa indicates when assumptions of type a are subject to contraction (duplication), and 
Drop a indicates whether they are subject to weakening (dropping), then linear, relevant, affine, and 
unlimited typing disciplines are all enforced by some subset of these classes. Linear types, then, are 
types that satisfy neither Dup nor Drop. This idea, suggested in one author’s dissertation lfj~6l . forms the 
basis of our prototype substructural programming language Clamp. 

Clamp programs are written in a Haskell-like external language in which weakening and contraction 
are implicit. This is easier for programmers to work with, but to specify the type system and semantics 
the external language is elaborated into an internal language that is linear (i.e. variables are used exactly 
once.) The internal language provides explicit dup and drop operations, which impose the corresponding 
type class constraints on their arguments. Thus, in the internal language one might think of dup and drop 
as functions with these qualified types: 

dup : Va. Dup a a —» a x a 

drop : Va/3. Drop a => a —> /3 —> /3 

In the internal language all nonlinear usage is mediated by the dup and drop operations. For example, 
the internal language term Ax.x + x is ill formed because it uses variable x twice, but the term 

Ax. let (xi ,X2) = dup x in xi +X2 

is well typed. Because elaboration into the internal language ensures that the resulting program is linear, 
it can then be checked using nearly-standard Damas-Hindley-Milner type reconstruction f8]| with type 
classes EH ED; improper duplication and dropping is indicated by unsatisfiable type class constraints. 
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Prelude functions with inferred signatures 


Contributions. We believe that Clamp offers substructural types with less fuss than many prior ap¬ 
proaches to programmer-facing substructural type systems. Throughout the design, we leverage standard 
type class machinery to deal with most of the constraints imposed by substructural types. Implementing 
type inference for Clamp (fj3]) is straightforward and it is also easy to extend the system with custom 
resource aware structures ( §2.4| ). The specific contributions in this paper include: 

• a type system design with polymorphic substructural types and a type safety theorem (fj2]); 

• a flexible system for managing weak and strong references ( §2.4| ); 

• a type checker with type inference derived from a type checker for Haskell (<Q); and 

• a dup-and-drop-insertion algorithm that is in some sense optimal (|3.1[). 


1.1 Clamp Basics 

In this section, we introduce the Clamp external language, in which dup and drop operations are implicit. 
The concrete syntax is borrowed from Haskell, but one prominent difference in Clamp is that each 
function type and term must be annotated with one of four substructural qualifiers: U for unlimited, R for 
relevant, A for affine, or L for linear. 

Three examples of Clamp functions, translated from the Haskell standard prelude, appear in figure [T| 
Their types need not be written explicitly, and are inferred by Clamp’s type checker. 

Consider the fst function, which projects the first component of a pair. Because we would like be 
able to use library functions any number of times or not at all, we annotate the arrow in the lambda ex¬ 
pression with qualifier U. This annotation determines the function type’s structural properties—meaning, 
in this case, that fst satisfies both Dup and Drop. (Note that this is a property of the function itself, not 
of how it treats its argument.) Because fst does not use the second component of the pair, this induces 
the Drop b constraint on type variable b. In particular, elaboration into the internal language inserts 
a drop operation for y to make the term linear: \{x , y ) -U> drop y x. The presence of drop, 
which disposes of its first argument and returns its second, causes the Drop type class constraint to be 
inferred. 

Function constU imposes a similar constraint on its second argument, but it also requires the type of 
its first argument be unlimited. This is because constU returns an unlimited closure containing the first 
argument in its environment. The argument is effectively duplicated or discarded along with the closure, 
so it inherits the same structural restrictions. Alternatively, we can lift this restriction with constL, 
which returns a linear closure and thus allows the first argument to be linear. 
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x | v | e\e2 | e [t£] | {ey^ef) | letp (x\,X2) = eine2 | Ini e | Inre (terms) 

case e of Inlxi —tey; Inrx2 —> ei | new ' 5 e | release"? e | swap ' 5 e\ with ei 
dup <?i as xi ,X2 in e2 | drop e\ in <?2 

X aq x:x.e | Aai[P].v | (vi,V2) | Iniv | Inrv | l | () (values) 

a | Ti —4 x 2 | Xy x x 2 | ti + t 2 I Unit | Ref' 5 T | Mofj.P => x (types) 


(K ] x \. K n x n ) 
s (strong) | w (weak) 

U (unlimited) | R (relevant) | A (affine) | L (linear) 

Dup | Drop 


(constraints) 
(reference qualifiers) 
(arrow qualifiers) 
(predicate constructors) 


Figure 2: Syntax of A c / 


2 Formalizing A c / 

To validate the soundness of our approach, we have developed A c /, a core model of the Clamp internal 
language. A,/ is based on System F fTTI with a few modifications: variable bindings are treated linearly, 
aiTows are annotated with qualifiers, and type class constraints lfl2l Il9ll are added under universal quan¬ 
tifiers. As an example of how one can define custom usage-aware datatypes in Clamp, A ( / also includes 
a variety of operations for working with mutable references. 

The A d type system shares many similarities with Tov’s core Alms calculus: "A,„ iV iflTt . Unlike the 
external Clamp language prototype (^3]», A c / provides first-class polymorphism and does not support type 
inference. 


2.1 Syntax of A c / 

The syntax of A c j appears in figure [2] Most of the language is standard, but notably arrow types and 
A terms in Clamp are annotated with an arrow qualifier (aq). These annotations determine which struc¬ 
tural operations a function supports, as well as the corresponding constraints imposed on the types in 
its closure environment. Unlike some presentations of linear logic, - 4 - here constrains usage of the 
function itself, not usage of the function’s argument. Thus one can call dup on a arrow but not on an 
-4* arrow. Type abstractions specify the type class constraints that they abstract over; their bodies are 
restricted to values, so unlike A terms, type abstractions do not need an arrow qualifier. 

The new '" 5 e and release ' 5 e forms introduce and eliminate mutable references. Each comes in two 
flavors depending on its reference qualifier (rq), which records whether the reference supports strong 
or merely weak updates. Weak (conventional) updates must preserve a reference cell’s type, but strong 
updates can modify both the value and type of a cell. 

Form swap ' 5 e\ with co provides linear access to a reference by exchanging its contents for a different 
value. The release operator deallocates a cell and returns its contents if it is not aliased. Store locations 
(ti) appear at run time but are not written by the programmer. 

To incorporate type classes, universal types may include constraints on their type variables. A con¬ 
straint P denotes a set of atomic predicate constraints Kx, each of which is a predicate constructor K 
applied to a type. For the sake of our current analysis, K is either Dup or Drop. 
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E ::= [•] | Ee \ vE \ E[zi\ \ (E,e) \ ( v,E ) | Inl£ | InrE (evaluation contexts) 

| case E of Ini x\ — > e\ ; Inr xi — > e 2 \ letp (xi ,X2) =E me | new ' 9 E | release ' 9 E 
| swap ' 9 E with e | swap ' 9 v with E | dup E as xi ,x 2 in e | drop E me 
H ::= f | • (stores) 


Figure 3: Runtime structures 


(H ; (kx:z.e)v) 
(At ; (A^[P].v)[^]) 
(ju ; new '" 9 v) 
vi ; swap '" 9 £ with V2) 
(H,£ H * 1 v ; release™ £) 
(H,£ i->' v ; release™ £) 
(fx,£ i -)' 1 v ; release s £) 
(At ; dup v as xi ,x 2 in e) 
(H ; drop v in e) 
(Ati ; E [e\]) 


(At ; {v/x}e) 

(At; {Zi/ai}v) 

(A i,£ i -)- 1 v; £) £ fresh 

(H,£ V2; (£,vi)) 

(At ; Ini v) 

(H,£ v ; Inr ()) when i > 1 

(m ; v ) 

(incr(locs(v);At) ; {v/x 2 } {v/xi}e) 
(decr(locs(v);At) ; e) 

(M2 ; E [e 2 ]) when (a^i ; f?i) i—> (/i2 ; e 2 ) 


Figure 4: Small-step relation 


2.2 Semantics 


The execution of A c / terms can be defined by a call-by-value small-step semantics with evaluation con¬ 
texts and a global, reference-counted store fj,. The run-time structures needed to define this small step 
relation arc given in figure [3] Reference counts are used to track when reference cells can be safely 
deallocated in the presence of aliasing. Exchange properties for the store are implicitly assumed. A 
selection of the small step relation rules are given in figure [4] focusing on the rules for reference cells 
and substructural operations. Most of the complexity here comes from the reference counts. 

The swap operator exchanges the contents of a cell in the heap with a different value. The release 
operator deallocates a cell and returns its contents if it is not aliased. However, if a cell has been aliased 
it decrements the reference count and returns a unit. The dup and drop operators manipulate reference 
counts as expected. 

A few metafunctions given in figure [5] arc necessary to maintain reference counts, similar to those 
in 0. The functions incr(f:;/j) and deer (£',fi) allow us to increment and decrement reference counts in 
the heap. Incrementing a location is straightforward, but a decrement must be defined recursively since 
deallocating the last pointer to a reference cell involves decrementing the reference counts of all cells the 
deallocated contents originally pointed to. 

The Iocs meta-function is a convenient way of extracting the multiset of locations that a value uses. 
Note that the + (or l±J) operator is a multiset operator which additively combines occurrences, and is used 
again in section [3Tj The Iocs function is also designed to operate on well-typed terms, so it only looks 


at one branch of a case expression, assuming that the other branch must share the same location typing 
context. 




incr(4 t >-F v,p)=£ i-F +1 v,p 

./ > 1 

incr({4,... ,4};M) = incr(4; • ■ ■ incr(4; ju)) 
deer ({4,... ,4};ju) = deer (4; • • -decr(4;ju)) 
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Iocs (£) = {£} 

Iocs (X, aq x:z.e) = Iocs (e) 

Iocs (e\ e 2 ) = Iocs(ei) + locs (e 2 ) 

( case e of \ 

Inlxi— > ep, = Iocs (e) + Iocs (e\) 
Inr x 2 -A e 2 J 


Figure 5: Reference count management 


Var TAbs 

Pi,P 2 ;F;£ F v: z domP? C aj 

P;x:t;- hi: t Pi;T;£F Aa, [P 2 ] -v : Vaj.P 2 => t 

Abs 

P;r,x:Ti;£ F e : t 2 P IF Constrain" 9 (r;£) 
pFIFA^r^.e: n t 2 
Case 

P;Ti;£i F ei : Tn + T 12 


TApp _ 

Pi: T; £ F e : Vaj.P 2 =>• z Pi IF {T ( /a,}P 2 

P];T;£ F e[Zj\ : 

App 

P;Fi;£ t F ei : T 2 — % z P;T 2 ;£ 2 F e 2 : t 2 
P;Ti +T 2 ;£i +£ 2 F ei e 2 : T 


P;T 2 ,x 2 i:Th ;£ 2 F e 21 : t 2 P;r 2 ,x 22 :Ti 2 ;£ 2 F e 22 : t 2 
P;Ti +r 2 ;£i +£ 2 F case ei of Inlx 2 i -A e 21 ;Inrx 22 -A e 22 : t 2 


Dup 

P;Ti;£i F e, : Z\ 

P;r 2 ,x 1 :T 1 ,x 2 :T 1 ;£ 2 F e 2 : t 2 P IF Dupti 
P;Ti +T 2 ;£i +£ 2 F dupei asxi,x 2 in ei : t 2 


Drop 

P;Fi ;£1 F C| : T] 

P;T 2 ;£ 2 F e 2 : t 2 PlhDropti 
P;Ti +r 2 ;£i +£ 2 F drop ei in e 2 : t 2 


Figure 6: Selected A c / term typing rules 


2.3 Term Typing 

Variable contexts T ::= xpTi,... ,x„:T„ associate variables with types, where each variable appears at 
most once. Location contexts (store typings) £ ::= £ s i-a s z Sl ...,£ w i-a^' 1 z w ,.. . associate locations (£) 
with their reference types Ref t, and distinguish between strong and weak locations; weak locations 
cany a reference count k to track aliasing. 

Linearity is enforced in A,-/ via standard context-splitting. Because F and £ are linear environments, 
we need operations to join them. The join operation + is defined only on pairs of compatible environ¬ 
ments, written Ti ^ T 2 and £1 — £ 2 . Two variable contexts are compatible so long as they are disjoint. 
Two location contexts are compatible if the strong locations are disjoint and the weak locations in their 
intersection agree on their types. Joining variable contexts appends the two sets of bindings together, 
while joining location contexts also involves adding the reference counts of any shared weak locations. 
Contexts are identified up to permutation. 

The term typing judgment (P;F;£Fe:T) assigns term e type z under constraint, variable, and 
location contexts P, F, and £. Selected typing rules for the core language appear in figure |6j and the 
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New LocW LocS 

P; r;£ h e : T 

P; T; £ R new"? e : Ref ' 9 1 P; ■■£ ^ % R £ : Ref w % P; ■;£ r R i : Ref s t 

ReleaseW Releases 

P-,T-XPe-. Ref"?r P- r;£be:Ref s T 

P;r;£ R release w <? : Unit + T P;T;£h release^ e : t 

SwapW 

PXiXXer.Re^z P- r 2 ;£ 2 hg 2 :T 
P;Ti +r2;Zi +£2 I - swap™ e\ with ei : Ref"?t x T 
Swaps 

P;Fi;£i h ej : Ref s ti P;T2;£2 R «2 : 

P;Ti +r 2 ;£i +£2 R swap s with ^2 : Ref s T 2 x T| 

Figure 7: A c / term reference cell typing rules 


typing rules for reference cells are given in figure [7} Consistency conditions £ 1 £2 and Ft -- T 2 arc 

assumed whenever contexts are combined. The core language typing rules split and share the linear 
contexts as needed, but are otherwise a natural extension of System F to support type class constraints. 

We impose a syntactic restriction, similar to Flaskell 98’s context reduction restrictions lH5l . on the 
form of constraints in type schemes introduced by the TABS rule: type abstractions may only constrain 
the type variables that they bind, and not compound or unrelated types. This simplifies induction over 
typing derivations for TABS since it means that no constraints on external type variables can be intro¬ 
duced by a type abstraction. Additionally, in rule Abs, the variable and location contexts are constrained 
by the function’s arrow qualifier, to ensure that values captured by the closure support any structural 
operations that might be applied to the closure itself; this constraint must be entailed (IR) by the con¬ 
straint context. Flere ConstrairT'RT; £) is shorthand for the appropriate set of Dup and Drop constraints 
applied to every type mapped in F and £, so that for instance Constrain 1- imposes no constraints, while 
Constrain R imposes only Dup constraints. 

The dup and drop forms constrain the types of their parameters in the expected way, by requiring 
their types to be members of the Dup or Drop type classes, respectively (again entailed by the constraint 
context). 

Since A c / supports both strong and weak references with different substructural properties, there are 
a variety of typing rules governing their usage. The swap operation needs to return both an updated 
reference and the old contents, so it packages those in a pair. Weak and strong forms of reference cell 
operations are provided, and it is safe to apply the weak operations to both strong and weak references. 
The release"? e forms are used to deallocate a reference cell and possibly retrieve its contents. Notably, in 
the case of a weak reference, since the contents could be linear, we preserve its linearity while allowing 
for aliasing by returning the contents of the reference only when the last alias to the cell is released, and 
unit otherwise. 
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(Dup cq, Dup 0:2) =>■ Dup(cq x a 2 ) 
(Dupa^Dupcq) =>• Dup(cq + a 2 ) 

() => Dup(cq a 2 ) () => Drop(cq a 2 ) 

() =>- Dup(oq 0C2) () => Drop(oq a 2 ) 


(Dropcq, Drop a 2 ) => Drop(cq x oq) 

(Dropcq, Dropcq) =>• Drop (cq + 012) 

()=^DupUnit ()=>DropUnit 

() =>• Dup(Ref w a) (Dropa) => Drop(Ref' ry a) 


Figure 8: Dup and Drop instances 


2.4 Type Class Instances 

Throughout the type system, type class constraints are propagated via entailment, Pi IF P 2 , which specifies 
when one set of type class predicates (P 2 ) is implied by another (Pi) in the context of the fixed background 
instance environment P s . For example, entailment allows our type system to derive that Unit x Unit is 
duplicable because Unit is. Rules for entailment are given by Jones llT 2 l and adapt naturally to this 
setting. The substructural essence of the type class system in Clamp is the set of base Dup and Drop 
instances r is , which appears in figure [8] 

Since pairs and sums contain values that might be copied or ignored along with the pair or sum value, 
their instance rules require instances for their components. Functions impose constraints on their closure 
environments when they are assigned a qualifier during term typing, so the instance rules for arrows 
depend only on the arrow qualifier. 

Dealing correctly with references is more subtle, as seen in A refURAL J2). I n Clamp, some references 
support strong updates, which can change not only the value but the type of a mutable reference. Flowever 
it is unsafe to alias a reference cell whose type might change. 

In A refURAL . the restrictions on reference types are given in a sizable table, but Dup and Drop in¬ 
stances make it easy to express these restrictions in Clamp. Clamp classifies references by the kind of 
updates they support: strong or weak. This is specified by the rq qualifier in the Ref" 7 type. 

Qualitatively, the constraints we impose are that: 

• Strong references may not be duplicated. 

• Only references with droppable contents may be dropped. 

• Only strong references support direct deallocation. 

• Weak references can be deallocated, but only return their contents when unaliased. 

The above four rules capture the same restrictions as A refURAL references. They also increase the 
expressiveness of the system by explicitly distinguishing weak and strong references and allowing for 
the deallocation of weak references. They are expressed in A c / with two type class instances and the 
typing judgments ReleaseW and RELEASES. 

As an example of the kinds of structures we can build using these rules, consider the type 

Ref w (fhandle) 

for a linear file handle fhandle. This weak reference can be aliased to provide shared access to the 
file handle, but cannot be dropped based on the type class instances, since fhandle cannot be dropped. 
Anyone that uses this reference must release the reference and close the file if necessary. 
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2.5 Type Safety 

Here we sketch part of the type safety proof; more details may be found in Gan’s thesis |[9]. 

The bulk of the work goes into proving preservation, and the key lemma in proving preservation 
relates constraints to bindings. Intuitively, this lemma says that structural constraints on a value’s type 
respect the structural constraints of everything the value contains or points to, via the variable and loca¬ 
tion contexts. Syntactic forms like DupF are used to denote the set of Dup constraints on all types in F, 
and similarly DupE applies Dup to all of the Ref rq T types mapped by E. Note that the lemma does not 
hold for arbitrary expressions. 

Lemma 1 (Constraints capture bindings). Suppose that P; T; E P v: z. IfP lb Dup r thenP lb (DupE, DupI'); 
if P IP Drop T then P lb (DropE, DropT). 

Proof. By induction on the typing derivation for v. □ 

Lemma [T] is essential to proving the substitution lemma (Lemma [2]). 

Lemma 2 (Substitution). If 

• P\Y,x\z x X\ h e : X, 

• P; ;E 2 F v : z x , and 

• Ei E2, 

then P;r;Ei +E 2 h {v/x]e : X 

Proof. By induction on the typing derivation for e, making use of lemma[T]in the A case. □ 

In proving Preservation, it is also useful to separate out a Replacement Lemma which specifies ex¬ 
actly how substitution interacts with evaluation contexts. 

Lemma 3 (Replacement). If P:Y:Y. P E [M] : z then 3t'.E| .E 2 .F 1 .r 2 such that 

• E = Ei + E 2 and T = Tj + T 2 and P; Ti; Ei PM: x' and furthermore 

• If P',YfX[ P M' : T 7 with Tj T 2 and Ej ^ E 2 , then PiTj +r 2 ;E 1 +E 2 h E[M'} : T for any 

V/'.F.E, 


Proof. By induction on E. □ 

Another key le mm a for proving preservation relates the Iocs function used to maintain dynamic 
reference counts with the store context that a value requires. To state this lemma, we overload the Iocs 
function to also return the multiset of occurrences (multiple for reference counted weak location stores) 
of locations in the domain of a store context. 

Lemma 4 (Store Contexts map Free Locations). If P:YX P e : z then Iocs (e) = Iocs (E). 

Finally, to prove preservation and type soundness we need to introduce store and configuration typ¬ 
ings which are given in Figure [9] The remainder of the type soundness proof is then mostly standard. 

Lemma 5 (Preservation). Ifh c (jUi ; <?i) : z and (jl\ ; tq) 1— > (pi_ \ ef) then \~ c (p.2 ; ei) : z 

Theorem 1 (Type soundness). If P c (• ; e) : z then either it diverges or it reduces to a value configuration 
(p ; v) such that P c (p ; v) : X. 
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St-Nil 


-Nil St-ConsW 

Ei h ju : £2 ■; -;Iv I - v: x 


St-ConsS 

E] hs M ■ E2 ' >' > £v I - V . T 


S b • : • Ei+E V b l— ^ ( v : ^ 2 ,^ l— T 


Ei +E V bfi)^ 1 v • E 2 ,^ 1 —> s T 


CONF 


Ei bM : £1 +£2 

b (H ; e) : t 


E2 h e : T 


Figure 9: Store and configuration typing 


3 Implementing the Clamp Type Checker 

We have implemented a type checker that infers Damas-Hindley-Milner style type schemes for Clamp 
terms. The type checker is an extension of Jones’s “Typing Flaskell in Flaskell” type checker lfl3l . Its 
source code may be found at https: //github. com/edgan8/clampcheck 

The process of modifying a Haskell type checker to support Clamp was straightforward and illustrates 
one of the strengths of Clamp’s design: It requires only small and orthogonal additions to a language like 
Haskell. Besides adding qualifiers to arrow types, we made three additions to a Haskell type checker: 

1. an elaboration pass that inserts dups and drops, 

2. Dup and Drop type classes and instances, and 

3. substructural qualifiers and constraints on arrow types. 

3.1 Inferring dups and drops. 

The elaboration pass is the bridge between a concise user-facing language and leveraging conventional, 
nonlinear type checking techniques. The pass takes as input a term with arbitrary variable usages; it 
inserts the appropriate dup and drop operations and renames the duplicated copies so that in the resulting 
term all variable usage is strictly linear. Structural properties are then enforced by the constraints imposed 
by dup and drop. 

Since different elaborations can lead to different static and dynamic semantics, we have proven that 
our algorithm generates an optimal elaboration in two senses: 

• It minimizes the program’s live variables. 

• It imposes minimal type class constraints. 

In what follows we define a core linear language to formalize and estabilsh these two points. 

An Abstract Linear Language To focus on the essential problems, we can work with an abstraction 
of the linear X calculus, Xn„. By modeling only usage and binding, A/,„ allows us to focus on inserting 
dup and drop operations independently of the particular types and term forms of a language. Its syntax 
is given in figure [TO] Extending the results to cover other term forms is straightforward. 

The product expression e\ ®C 2 abstracts multiplicative forms such as pair's and function applications— 
that is, pairs of expressions where both will be evaluated. The sum expression e\ &<?2 abstracts additive 
forms such as linear logic’s additive conjuction, and the relationship between the branches of a case— 
that is, pairs of expressions where exactly one will be evaluated. 
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e ::= x \ Xx.e \ e\®e 2 \ e\tkei 

ae ::= x \ Xx.ae \ ae\ ®ae 2 \ ae\ &ae 2 | dup T in ae | drop T in ae 

Figure 10: A/,„ syntax 


(unannotated terms) 
(annotated terms) 


L-Var 


{*} F x 


L-Abs 

r + {x} h ae x ^ r 
r F Xx.ae 


L-Pair 

r 1 F ae 1 T2 F ae 2 

Ti +T2 F ae\ <g> ae 2 


L-Choice 

rhaei F\~ae2 

r F ae 1 & aei 


L-Dup L-Drop 

ri+r 2 + r 2 Fae Y\\~ae 

ri +T2 F dup T2 in ae H +T2 F drop iiF in ae 


Figure 11: Annotated expression well-formedness 


Expressions, e, are unannotated and don’t explicitly satisfy linear usage constraints. Annotated ex¬ 
pression, ae, use dup and drop operations to explicitly specify nonlinear usage of variables. The dup and 
drop operations work over contexts, F. which are multisets of variables 

The contexts T in A/,„ manage scope and binding by restricting contraction and weakening to explicit 
dup and drop annotations, but do not track the types of variables. In order to avoid the messy but 
straightforward process of generating names and renaming variables when inserting a dup, we think 
of contexts as multisets ( e.g ., {x,x,y,z, ■ ■.}) of in-scope variables, or equivalently as functions from 
variables to natural numbers. Thus Fix) will be used to denote the number of times x appeal's in T. 

We use these multiset contexts to define a notion of well-formedness in figure |TT] which describes 
when an annotated term ae in Xu,, properly accounts for all nonlinear usage of its variables through 
explicit dup and drop operations. 

Inference Algorithm An inference algorithm for annotating terms is given in figure [12] The strategy 
is to recursively transform a term bottom-up based on the free variables fv in each recursively trans¬ 
formed sub-term. Note that the fv function always returns a set and that n and \ denote the standard set 
intersection and difference operators. 

Dup operations are inserted where the free variables of two sub-terms of a multiplicative form (e.g., 
application, but not branching) are discovered to intersect; drops are added under binders when the bound 
variable is not free in its scope, and when a variable used in one branch (say, of an if-then-else) is not 
free in the other. 

We outline the key steps in our optimality argument here; additional details may be found in l9l . 
Lemma [6] states that the algorithm is sound. 

Lemma 6 (Soundness). fv(e) F infer(e) 

If ae is an annotation of e, then fv(<?) C f v(ae), so lemma|7]shows that our algorithm in fact generates 
an annotation which requires a minimal context Y for well-formedness. 

Lemma 7 (Minimal contexts). IfYYae then i\'(ae) C Y. 

With some technical lemmas, we can then prove that the algorithm introduces no unnecessary dups 
or drops on variables. In order to compare different potential annotations of the same term, we de- 
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infer (x) = x 

f Ax. infer (e) ifxGfv(e); 

infer (Ax.e) = < 

I Ax.drop x in infer (e) otherwise 
infer (<?i < 8 )^ 2 ) = dup fv(^i) nfv(eT) in infer(^i) 0 infer(^ 2 ) 

infer (<?i&<? 2 ) = (drop fv(<? 2 )\fv(o) in infer(ei)) & (drop fv(<?i)\fv(<? 2 ) in infer^)) 

Figure 12: Inference algorithm 

fine a function erase : ae —> e, which removes dup and drop annotations from an annotated term in the 
straightforward way, yielding an unannotated term. It should be evident that erase) infcr(<?)) = e. 
Lemma 8 (Forced drop). If T F ae, F (x) > 1, and x f fv (erase (ae)), then ae contains a subterm 
drop V in ae' such that x G V. 

Lemma 9 (Forced dup). If F F ae, T (x) < 1 , and there exists a subderivation F v F ae s of F F ae with 
r, (x) > 2, then ae contains a subterm dup V in ae' such that x G F 1 

Lemma 10 (No Unnecessary Drops). Let ae = infer (e). If ae contains a subterm drop F,/ in ae s with 
x G I \i then any other well-formed ae' with erase {ae') = e contains a subterm drop T (/ in ae s with x G 

Lemma 11 (No Unnecessary Dups). Let ae = infer (e). If ae contains a subterm dup T f / in ae s with 
x G T d then any other ae' with erase {ae') = e and F F ae' for F (x) < 1 contains a subterm dup Tin ae s 
with x G r d . 

3.2 Constraint processing. 

After the dup and drop insertion pass, type inference can proceed without needing to count variable 
usages or split contexts, since the insertion pass has made every dup and drop operation explicit. With 
the exception of the extra constraints imposed on closure environments, inferring types for the Clamp 
internal language is like inferring types for Haskell. For the constraint solver, the type classes Dup and 
Drop and their instances are no different than any other type class. 

Type checking in this system is thus separated into two self-contained steps: first, usage analysis 
as performed by elaboration, and second, checking substructural constraints in the same manner as any 
other type class system. A similar division was used by de Vries et al. to integrate a uniqueness typing 
system into Damas-Hindley-Milner Ifl 8 l . 

In Table [I] we present the sizes of the components of our Clamp implementation. It compares favor¬ 
ably to the implementation of languages such as Alms iflTl . whose type inference engine is 15,000 lines 
of Haskell. The dup/drop insertion sits on top of the stack and is the main addition we have had to make 
to a Haskell type checker design. Besides that, we have included the base set of type class instances and 
altered arrow kinds throughout. 

4 Related Work 

Of the existing work in 1 inear type systems, we will focus here on those which develop general purpose 
polymorphic linear types. Research on the mathematical expressiveness of linearity 01 or more tailored 
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Component 

Lines of code 

Dup/drop insertion 

160 

Type class instances 

60 

Syntax and Types 

703 

Parser/Lexer 

319 

Unification Engine 

373 


Table 1: Type checker code breakdown 


use cases ITOl for instance often do not aim at broad usability and polymorphism. 

The first linear type systems derive directly from intuitionistic linear logic, and use the exponen¬ 
tial “!” to indicate types that support structural operations |[H |6]]- Some later type systems, in order to 
support parametric polymorphism over linearity, replace “!” with types composed of a qualifier and a 
pretype E1I201. so that all types in these languages have a form like q T. Similarly, the Clean programming 
language makes use of qualifier variables and inequalities to capture a range of substructural polymor¬ 
phism |(5] HU- Though Clean uses uniqueness rather than linear types, many of its design decisions can 
be applied in a linear settings as well. 

More recent languages such as Alms ifTTl and F° Ill4l eliminate the notational overhead of annotating 
every type with substructural qualifiers by using distinct kinds to separate substructural types. Thus, 
rather than working with types like A file, a file type in Alms can be defined to have kind A. Like Clean, 
Alms is highly polymorphic, but it makes use of compound qualifier expressions on function types, as 
well as dependent kinds and sub-kinding. 

Compared to type systems like those of Clean and Alms, we believe Clamp offers advantages in 
simplicity and extensibility. Like Alms and F°, Clamp avoids the burden in Clean of annotating every 
type with a qualifier. Type classes themselves are a general and powerful feature; for a language that is 
going to have type classes anyway, the Clamp approach allows adding the full spectrum of URAL types 
with little additional complexity for programmers and type checkers. Programmers already familiar with 
type classes will be well prepared to understand Clamp-style substructural types. 

Further, type classes provide a clean formalism for constraining state-aware datatypes such as the 
system of weak and strong mutable references found in Clamp ( §2.4[ ). Finally, we anticipate that user- 
defined Dup and Drop instances, not yet supported by Clamp, will allow defining custom destructors and 
copy constructors, which should enable a variety of resource management strategies. 

However, compared to Alms and Clean, Clamp does not provide as much polymorphism because 
each arrow is assigned a concrete qualifier. Consider, for instance, a curry function in Clamp. Unlike in 
Alms or Clean, Clamp requires different versions for different desired structural properties. For instance, 
two possible type schemes for a curry function are 

(Dup a, Drop a) => ((a, b) -U> c) -U> a -U> b -U> c 


and 

((a, b) -L> c) -U> a -L> b -L> c. 

We believe that extending Clamp with qualifier variables and type class implications could increase its 
expressiveness to the point where curry has a principal typing. 
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5 Future Work 

5.1 Custom dup and drop 

In Clamp's current design, the semantics of dup and drop are fixed. Allowing programmers instead to 
define their own implementations of dup and drop on user-defined types would enable scenarios similar 
to those possible in C++ via copy constructors and destructors. Programmers could then define data types 
that automatically manage resources in ways that meet particular needs; but unlike in C++, we believe 
this could be done without unsafe operations. 

Programmers could define types and instances to manage their memory in whatever way is most 
appropriate, for instance by choosing between deep-copy and shallow-copy dup operations (or perhaps 
some hybrid approach), or between eager and lazy drop operations. For such a system to be practical, it 
is important that the dup/drop-insertion algorithm be easy to understand, since the insertion of dups and 
drops can affect the dynamic semantics of the language. 


5.2 Polymorphic Arrows 

In most cases, Clamp allows programmers to define functions that are inherently polymorphic over the 
substructural properties of their arguments. In these cases, a function that uses one of its arguments 
linearly can accept any type, whether it satisfies Dup or Drop, for that argument. However, this is not the 
case for function types, which are annotated with fixed qualifiers determined at the function definition 
point. 

Alms is able to accommodate more polymorphic arrow types by introducing a subtyping relation on 
qualified arrows liTTl . and it refines the types of arrows further by introducing usage qualifiers that depend 
on the substructural properties of type variables. This allows one to write a function whose qualifier is 
inferred from the closure environment and inherits any polymorphism present in that environment. 

There are many options for increasing the polymorphic expressiveness of Clamp without resorting to 
the complexities of subtyping. One could make qualifiers into first class types and allow quantification 
over qualifiers in arrow types. This is implemented in an ad-hoc way in our current type checker. 

The idea of expanding the language of qualifiers could also be profitable in Clamp. This often means 
annotating arrow types with the types of their closure environments, and in a sense assigning them a 
closure-converted type. The dup and drop instances for arrows could then use the closure environment 
types to determine the arrow type’s substructural properties. 


5.3 Implementation 

The current implementation of the Clamp type checker reflects A c /, and could benefit from the addition of 
some standard language features found in full Haskell. In particular, the addition of algebraic datatypes, 
user-defined instance rules, and a module system would allow programmers to define libraries that expose 
custom types with varying substructural properties. 

It would also be interesting to implement a compiler for Clamp that takes advantage of substructural 
properties for reference-counted memory management (7j. Eagerly reusing the storage occupied by 
linear and affine values may offer particular performance advantages, and substructural analyses can 
enable a variety of other optimizations as well 0{2T]. 
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6 Conclusion 

Clamp introduces techniques that make it easier and more desirable to add substructural types to func¬ 
tional programming languages. The external / internal language distinction gives us both a programmer 
friendly syntax and a direct path to type inference. The Dup and Drop classes also support polymor¬ 
phism over the URAL lattice and can represent state aware types such as strong and weak references. 
Type classes are an expressive and well-established language feature, and Clamp shows that they can 
serve as a base for substructural types. 
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